\section{Retrospectiva de la iteración}

  A modo de evaluación del trabajo realizado, vamos a destacar algunos de los inconvenientes que
  tuvimos para poder seguir la metodología SCRUM de forma fiel. En particular, creemos que hay
  algunos elementos que en el contexto de este trabajo hicieron que resultara un poco forzada la
  aplicación de la metodología.

  En primer lugar, y como ya se anticipó en la sección anterior, no contábamos con la posibilidad de
  dedicarle tiempo al trabajo de forma regular. Si bien la distancia física no fue un gran problema
  de comunicación, la realidad es que el trabajo no fue muy homogéneo a lo largo de las semanas que
  duró la iteración. Síntoma de esto es la forma claramente escalonada del burndown chart, donde se
  ve cómo hubo momentos bien marcados donde se avanzó mucho, seguidos de una meseta. Esto también se
  notó en la falta de reuniones diarias formales, que tan importantes son en SCRUM: el problema no
  fue falta de disciplina para seguir la metodología, sino que en general durante los días de semana el
  avance era muy lento.

  Como también se adelantó previamente, la gran diferencia entre el diseño final y las ideas que se
  tenían en mente al momento de definir las stories de funcionalidad hizo que no pudiéramos reflejar
  en términos de stories y sus tareas asociadas cuál era el avance del trabajo. En muchos casos, la
  implementación particular de las técnicas se limitó a definir un preprocesador y en otros casos
  directamente no fue necesario implementar nada, como ocurrió en el caso de los disminutivos o
  aumentativos: al detectar la raíz de la palabra, no importa qué prefijos o sufijos tenga ésta, la
  raíz es la misma y al matchearla, encontramos el insulto sin necesidad de hacer ningún
  procesamiento extra. Si bien se fueron dando por resueltas las stories a medida que el producto
  cumplía la funcionalidad, al momento de finalización del sprint no se ve reflejado el hecho de que
  ya se tiene resuelta gran parte de funcionalidad que quedó fuera de la iteración.

  Previo al desarrollo del código fuente, hubo gran parte del trabajo que consistió en discutir de
  forma grupal una manera efectiva de resolver el problema. Antes de modelar la interacción de las
  entidades de dominio relevantes al problema, hizo falta encontrar la solución: pensar realmente
  qué era lo que hacía que los humanos entendieran ciertos comentarios como insultos y produndizar
  en el dominio que ibamos a tener que modelar. Encontramos que este tipo de trabajo (que es normal
  que ocupe un lugar importante al principio del proyecto) no es fácil de congeniar con el modelo de
  trabajo de SCRUM, donde toda unidad de trabajo debe asignarse a un integrante del equipo y hay
  tareas bien definidas. Quizás esto en general no sea un problema en iteraciones posteriores, donde
  este tipo de trabajo no es tan usual.

  Como puntos positivos, pensando en una posible continuación del trabajo, creemos que vale la pena
  rescatar algunos puntos imporantes que encontramos. Independientemente de que creemos que no
  estamos en las condiciones ideales para ejecutar SCRUM de forma pura, encontramos unas cuántas
  ventajas que se deberían seguir explotando.

  La primera es inherente al modelo de ciclo de vida iterativo incremental: es muy valioso contar
  tras la primera iteración con una versión inicial del sistema que sea fácilmente validable, más
  allá de que haya parte de la funcionalidad que no esté presente todavía en el producto.

  Por otra parte, y a pesar de que hubo una distancia entre la división real de tareas y la planeada
  originalmente, se puso mucho foco en que todo el tiempo cada integrante tuviera en claro qué tarea
  debía estar realizando y qué estaba haciendo el resto del equipo. Esto se vio facilitado por la
  comunicación fluida, incluso habiendo faltado las reuniones diarias de SCRUM.
